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1. Abstract 

This paper presents a simple programming system based on a clear separation of value- oriented program- 
ming and objectr oriented programming [MacLennan82 , MacLe nn an83a] . The value-oriented component 
is a conventional functional programming language. The object-oriented component is based on a 
model of objects and values connected by relations, and on production system-like rules that determine 
the alteration of these relations through time. It is shown that these few basic ideas permit simple pro- 
totyping of a software development environment. 



2. Introduction 

2.1 Goals 

Our goal has been to design a programming system that combines in one system the best features of 
value-oriented programming and object-oriented programming. The following two sections discuss 
these two programming paradigms and their advantages and disadvantages. This is followed by a 
description of a paradigm that attempts to combine the best features of both. A programming system 
based on and supporting this paradigm is then discussed. The system is illustrated by several applica- 
tions to components of programming environments. 

2.2 Value- Oriented Ph*ogra mining 

There are a number of possible definitions of value- oriented programming | MacLennan82, McGraw82, 
MacLenn an83a] . It is most accurately considered programming without the use of explicit state 
changes. Since the assignment operation is the major programming language construct for effecting 
state changes, value-oriented programming has also been characterized as assignmentrless programming. 
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Also, since variables are the things that assignment operations change, and are the media in which the 
state is represented, value-oriented programming has also been characterized as variable-less program- 
ming. There are a number of species of value-oriented programming, including applicative program- 
ming [Lajidin64, Lajidin66, Burge75j, functional programming [Backus78. HendersonSO, MacLen- 
nan86], equation al programming ^Hoffman84], logic programming Kowalski79^ and relation aj program- 
ming [ MacLennan81 , MacLennan83b] . 

Variables and the assignments to them are some of the most common elements of programs in con- 
ventional languages. Why w'ould one want to eliminate them? The advantages of value-oriented pro- 
gramming include ease of program derivation, ability for algebraic manipulation, ease of proof of pro- 
perties, ease of analysis, evaluation order independence, and very-high- level operations. Examples of 
value-oriented programming languages include “pure LISP,’’ PROLOG, KRC and Backus’s FP. 

Value-oriented programming is not without disadvantages. These result directly from the absence of 
state changes, since this means it is hard to deal with temporal change. Thus, it is difficult to program 
those applications for which temporal change is an essential element. Examples of these applications 
include databases, graphics, realtime programs, interactive systems and operating systems. Many of the 
components of programming environments fall into the above categories, such as editors, version con- 
trol systems, debuggers, documentation management systems, configuration management systems, etc. 

2.5 Object-Oriented Programming 

There have been many definitions of oh jecir oriented programming [Lomet76, Lomet80, Robson8l, 
Rentsch82, MacLennaii8 2, MacLennan83a] . One view, perhaps the most common, is that the essence 
of object-oriented programming is data abstraction and information hiding. This seems to be the view, 
for example, in |Buzzard85|. We prefer to call such languages data abstraction languages. 

This paper takes a different view of object-oriented programming, a view proposed by Alan Kay 
|Kay77j and others, namely, that the essence of object-oriented programming is simulation. This view 
is particularly appropriate to systems that must deal explicitly with the passage of time and the alteration 
of objects through time. These systems include interactive systems, graphics systems, operating sys- 
tems, file systems, editors, database systems and version control systems. Indeed, aU the major 
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components of a software development environment fit nicely into the simulation paradigm and the 
object-oriented view [RobsonSl . 

Unfortunately, conventional object-oriented languages, such as Simula |Dahl70j and SmaJltaJk 
GoldbergSS], are built upon the framework of a conventional procedural language, which does not take 
full advantage of the simulation paradigm. 

The approach to object-oriented programming taken in this work directly supports the simulation 
paradigm. This can be summarized as follows: 

t Computer objects correspond to external objects. 

• The behavior of computer objects models the behavior of external objects. 

• Objects are classified according to their behavior. 

The advantages of object-oriented programming languages result from their being based on the simula- 
tion paradigm. In particular, they are well-suited to deal with time and changes of state in time. Thus 
they are ideal for dealing with applications for which temporal change is an essential element, such as 
programming environments, databases, graphics systems, etc. [RobsonSl]. 

Object-oriented programming also seems to be quite natural, especially for those without a lot of 
computer experience [ Goldberg77| . This is probably because there is a close correspondence between 
thinking about computer objects and reaJ-world objects. In many situations the object-oriented program 
is derivable from real-world situation it is intended to model. 

The disadvantages of object-oriented programming are the advantages of value-oriented program- 
ming: (1) it is difficult to reason about things that change in time; (2) object-oriented languages provide 
little ability for algebraic manipulation (although this perhaps could be remedied); and (3) the analysis 
of object-oriented programs can be hard. 

2.4 A Solution: Dyad 

Based on these considerations we are developing a programming paradigm, and a programming system 
to support it, that combines the advantages of object-oriented programming and value-oriented pro- 
gramming. It is called Dyad to reflect the fact that it is a whole comprising two distinct units: 
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A (alpha) — An applicative (value-oriented) component 



• n (omega) — An objecU oriented component 

Thus the Dyad system accommodates both value-oriented programming and object-oriented program- 
ming. The goal of this research is to investigate the advantages and disadvantages of programming in a 
language, such as Dyad, that clearly separates yet suppx>rts both the value- and object-oriented para- 
digms. 

We will not describe here the applicative language (A), since it is conventional and similar to previ- 
ous applicative languages (KRC, SASL, etc.). The object-oriented language (H ) is unconventional, 
however, and will be described in some depth in the following section. 

5. TTie Object-Oriented Component: Q 

5.1 Structure of H 

In designing the object-oriented component of Dyad, we have attempted to deal directly with the needs 
of simulation, and not to include any feature just because it is found in other languages. There are 
several results of this fundamental approach. First, H lacks many of the accouterments of conventional 
languages, such as variables, assignment statements and most control structures. Second, concurrency 
is the norm; as in the real world being simulated, things happen sequentially only if specifically 
arranged to do so. 

We turn now to the structure of Q . There are two major issues: The nature of the simulated 
universe of objects and their relationships, and the means for describing how this universe evolves in 
time; i.e., for describing the behavior of the objects in terms of the relationships. These issues are dis- 
cussed in the following two sections. 

5.2 Object- Relationship Space 

It will be seen that the object-relationship space is similar to several familiar ideas including the 
knowledge representation languages (semantic nets) used in expert systems |Findler79], the entit>'- 
relationship approach to databases Chen76j, and relational databases [Codd70]. Thinking of these will 
simplify understanding the H space. 
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The n object-relationship space is populated by a number of atomic objects connected by relation- 
ships. The only properties an object has are those it gets by virtue of the relationships; this is what we 
mean by the objects being atomic. Besides objects being related to objects, objects can also be related to 
values by the relationships; this provides the connection between the object-oriented and value-oriented 
components of Dyad. 

Relationships axe usually expressed in a predicate- logic style. For example, if M and T are particu- 
lar objects, then a part of the state of a simulation might be expressed by the following relationships: 

Missile (M), Moving (A/), Position ( 25,60], A/), 

Target [T), ^Destroyed (T), Position ([ 18,32], T) 

This can be read, “A/ is a missile, M is moving, [25,60] is the position of M, T is a target, T is not 
destroyed, and [ 18,32] is the position of T.” 

3.S Transaction Rules 

We have discussed how the state of the simulated universe is expressed as atomic objects connected by 
relationships. We now turn to the transaction rules, which are used to describe state changes. These 
rules are similar to the production rules used in many AI applications [Newell72]. They are also similar 
to logic programming clauses [Kowalski79] (although there is no backtrack) and, most relevantly, to 
causal laws. 

The relation of the transaction rules to causal laws can be understood by considering the description 
of causal relationships in the real world. There are two kinds of causal laws that can be used for this 
purpose: entity- oriented \a.v/s and evenir oriented la,v/s. 

In the entity-oriented (or object-oriented) approach the law describes how an object of a given kind 
behaves in situations of a given kind. Hence, causal laws of this sort are associated with classes of 
objects. Languages such as Smalltalk and Simula are based on this model of causality. 

An alternate model of causality, the event-oriented, says that a causal law relates two kinds of 
events. Causal laws do this by stating the manner in which events of the first kind cause events of the 
second kind. This is the model we have adopted in Q . The event-oriented approach is more general 
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than the entity-oriented approach, and in fact subsumes it. The event-oriented approach also permits 
the convenient description of causal relationships in which two or more objects participate as equal 
partners. Such relationships do not have to be considered properties of any of the objects. This is a 
problem in Smalltalk, Simula and similar languages [ GoldsteinSO j . 

Thus our goal is to describe causal relationships in terms of two classes of events standing in the 
relationship of cause to effect. That is, a causal law tells us how' a present situation (set of relationships) 
leads to a, future situation (set of relationships). Thus a causal law has two parts: 

• A cause, which describes a present situation in terms of a set of relationships; 

• An effect, w'hich describes a future situation in terms of a set of relationships. 

The cause part is just a set of inquiries about tuples in the relationships in the database. For example, 
the following cause part tests for a particular situation in the state space: 

Missile(m), Moving(m), Position (p , m) , Target(t), ^Destroyed( i ) , Position( p , t) =?> • * * 

This can be read, there is a missile m, and m is moving, and some p is the position of m, and there 
is a target t, and t is not destroyed, and p is the position of then 

The effect part is a set of transactions that add tuples to, or delete tuples from, relationships. For 
example, the effect part: 

• * * -^Moving(m), Destroyed( m) , Destroyed( t ). 

says that the ‘Moving’ property is to be removed from m, and that the ‘Destroyed’ property is to be 
added to both m and t. 

5.4 Detailed Discussion 

Having described the overall structure of Q , we now turn to a more systematic presentation of its facili- 
ties. The presentation here will be informal. The formal syntax will be found in Appendix A; the for- 
mal (denotational) semantics is presented in [MacLennan83aj . 

The basic construct is the rule, which has the form 



cause 



effect 



The cause describes a possible situation in a space of objects connected b\ relations. If that situation 
holds, then the rule may be applied, which means that the actions described by its effect part will be 
performed. Rules are executed indivisibly, which means that it is guaranteed that the situation still holds 
when the actions are performed. 

There is normally no order implied between rules; they can be tested in any order. However, rules 
can be connected by the word else when a particular order must be imposed: 

causcj = 5 > effecti 
else causc2 => effect^ 

else cause^ => effect^ 

In this case, the second and succeeding rules are tried only when the preceding rules have failed. 

The cause part of a rule describes a situation in terms of one or more conditions, which represent the 
presence or absence of relationships between objects: 

conditionij condition2, • . • ; condition^ 

All of these conditions must be satisfied before a rule can be applied. 

A condition for testing for the presence of a tuple in a relationship has the form: 

primary ( pattemi, pattem2f . • • , pattern^ ) 

The primary is an expression (usually just an identifier) that evaluates to a relation. The following list 
of patterns defines a tuple pattern. Each pattern in the list can be either a free (i.e., undefined) variable, 
or an expression containing no free (i.e., only bound) variables. An expression is evaluated during the 
matching process, and matches a value equal to the result of its evaluation. A free variable will match 
any value, but becomes bound to that value during the matching process. The special free variable ’ 
can be used to match anything without binding a variable name. 

A condition for testing for the absence of a tuple from a relationship has the form: 



^primary ( pattemi, pattem2, • . • ; pattern^ ) 



This condition succeeds only if there is not a tuple of the specified form in the relation that is the value 
of the primary. 

Finally, as a convenience we permit cance/ conditions: 

^primary ( patteruY^ pattern 2, • • • ; pattern^ ) 

This tests for the presence of a tuple of the specified form, just as the first kind of condition, but it has 
a side effect of deleting that tuple if the rule is applied. Although, this could be programmed explicitly', 
the situation is common enough that it is important to reflect it in the notation. 

The effect part of a rule is composed of a sequence of transactions: 

transactioni, transaction2, • • • , transaction^ 

These transactions can be performed in any order or in parallel. However, their execution forms an 
indivisible unit. 

The transactions are of four kinds: assertions, denials, calls and sequential blocks. 

An assertion is a transaction of the form: 

primary ( expressions^ expression2, • • * ; expressions^ ) 

Its effect is to add to the relation that is the value of the primary the tuple < V'l, V2, . . . , V^> , where 
each V, is the value of expression^. TypicaUy these expressions contain variables that were bound in the 
cause part of the rule. 

A denial has the form of an assertion preceded by a negation sign: 

^primary ( expressions, expression2, • • • ; expression^ ) 

Its effect is to delete the specified tuple from the specified relation. If this relation does not contain this 
tuple, then an error condition holds (fl error handling is beyond the scope of this paper). 

A call is a transaction of the form: 

primary { expressions^ expression2, • . . , expressions,^ } 

Its purpose is a form of synchronous communication performed by sending a message through one rela- 
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tion, and waiting for a reply to be returned through another relation For example, the call 



P{E. F) 

has the effect of performing the assertion 

P{a, E, F) 

Here a is a newly generated relation that will be used for receiving the reply. This assertion presum- 
ably requests some actions to be performed by other rules (which are watching P) . When the actions 
are completed, an acknowledgment or reply will be placed in the a relation, which permits the calling 
rule to complete. Note that rules containing calls in their effect parts are not considered indivisible. 
The formal definition of calls through their reduction to basic rules is described in | MacLenn an83a . 

The last kind of transaction is a sequential block, which has the form: 

{ statementi; stattmcnt^'y ‘ ; statement^ } 

The effect of this construct is to execute the component statements in order. A statement is simply a 
rule, simple or compound, with the additional characteristic that its cause part (and the ) can be 
omitted. This reflects the fact that in a sequential block the performance of actions may be conditioned 
solely on the performance of the preceding statements. 

A user normally interacts with an H system by typing statements. Thus the form of an Q terminal 
session is: 

statementi] 

8tatement2\ 



statcmtntj^\ 

Many of the statements typed interactively are isolated effects containing a single call. For example, to 
define ‘Contents’ to be a new private relation, a user would enter: 

Define {Private, “Contents”, newrel {} }; 

Finally, we need a means for manipulating groups of rules as a unit; this is the rule denotation and has 
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the form: 



<< compound — rule I . compound — rult^- compound — rulc^ . >> 

Notice that each compound rule is terminated by a period. (A compound rule is simply a rule that may 
contain elses.) 

3.5 Alternate Notations 

We also permit predicates to be written in a pseudo-natural notation that comes quite close to the infor- 
mal meaning of the predicates: 

If a missile is moving, a target is not destroyed and the position of the missile is the position of a 
target 

then the missile is not moving, the missile is destroyed and the target is destroyed. 

Notice that the notation permits a limited amount of subordination and anaphoric reference. This 
pseudo-natural notation is actually very simple to parse; it does not require the use of any sophisticated 
natural-language- understanding techniques. 

We have also investigated two-dimensional, form-based notations, since they can be easily under- 
stood by many people. These alternative syntactic representations are described in [ MacLennan84] ; an 
implementation of a pseudo-natural notation is described in [Ufford85j. 

4. Naming and Classification 
4.1 Naming 

Most programming languages have built-in declarative constructs for binding names to their meanings; 
there are no such constructs in H . Rather, naming is implemented within Q by the use of objects, rela- 
tions and causal laws. We have taJcen this approach for two reasons. First, in an interactive system 
bindings are created and destroyed through time. This temporal change implies that name directories 
are objects, and hence that Q is the appropriate vehicle for dealing with them. Second, a loose cou- 
pling between the naming strategy and the language permits experimentation with alternative naming 
strategies, which is appropriate in a prototype system such as Dyad. 
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The current Dyad naming strategy makes use of objects called directories that bind names (strings) 
to values or objects. This is accomplished through two relationships, ‘Directory’ and ‘Binds’. The 
meaning of Directory (d) is that d is a directory; the meaning of Binds(d.n,i) is that directory d binds 
name (string) n to object or value x. 

Bindings are established by the procedure call: 

Define {d , n, x } 

In the simplest case this procedure is implemented by the following rule, which makes the appropriate 
entries in Binds: 

^Define (a, d, n, x), Directory (d) => Binds (d, n, x), a (n) 

(The extra parameter a is used for return from the procedure; see calls in Section 3.4.) In practice it is 
desirable to allow the rebinding of already bound names. This is easily accomplished by the compound 
rule : 

*Define (a, d, n, x), Directory (d), *Binds (d, n, y) 

=> Binds (d, n, x), a (n -h “ redefined”) 

else "^Define (a, d, n, x), Directory (d) ==> Binds (d, n, x), a ( n -r “ defined”) 

The first rule handles the case where n is already bound to some y; this binding is discarded. In either 
case the caller a is returned a message indicating that n was (re)defined. 

When n executes a rule (more correctly, when the rule is activated), it must look up the meanings 
of all the names that occur in that rule. Although this lookup operation is built into the system, its 
effect is the same as executing the procedure call ‘Lookup{n , d}’, w^here d is the “current” directory. 
The default implementation of Lookup is: 

^Lookup (a, n, d), Directory (d), Binds (d, n, x) => a (x) 

That is, we return to the caller a the object x to which the name n is bound by the directory d. 

That the Dyad naming system is defined within Q adds considerable flexibility to the system. To 
implement a different naming strategy all we need do is change the definitions of Define and Lookup. 



For example, if we wanted to permit lookup operations to follow a path from directory to directory, we 
could do this by defining a new relation Path and by making the appropriate change to Lookup; 

^Lookup (a, n, d), ^Binds (d, n, i), Path (d, e) => Lookup (a, n, e) 
else ^Lookup (a, n, d), Binds (d, n, x) => a (x) 
else ^Lookup (a, n, d) =?> a (Nil). 

The first rule detects if the sought name is not bound in the current directory, and forwards the search 
to the next in the path. We have also added here a rule to detect unbound names. 

4.2 Information Hicfing 

In a simulation it is often necessary to implement an object in terms of lower level objects. To preserve 
the integrity of the simulation it is important to distinguish those objects and relationships that are part 
of the simulation (i.e., correspond to objects and relationships in the system being simulated), from 
those objects and relationships that are not part of it (i.e., do not correspond). There is also a software 
engineering reason for making this distinction, namely, facilitation of the modular decomposition of the 
system. 

Although both Simula-67 and Smalltalk permit objects to be used in the implementation of other 
objects, neither language enforces the boundary between these levels of abstraction. Such enforcement 
is a natural extension that has been included in more recent languages (including newer versions of 
Simula). It is, I believe, the reason that object-oriented languages are commonly identified with data 
abstraction languages and languages supporting information hiding. 

It is for these reasons — the support of both simulation integrity and modular decomposition — that 
we have included in Q facilities for enforcing levels of abstraction. This enforcement is accomplished 
by controlling the kinds of access to the relations permitted to various parties. In particular, rather than 
being bound directly to relations, relation names are bound to capabilities [Dennis66] referring to the 
relations. Each such capability may bear from zero to three rights, the permitted rights being read, insert 
and delete. These rights correspond to the ways in which relations can be used in rules: read for use in 
the cause part, insert^or use in an assertion in the effect part, and delete for use in a denial in the effect 
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part. 



An example will illustrate how capabilities can be used to enforce information hiding and levels of 
abstraction. Suppose that we intend to implement a system service such as an editor. It is intended 
that users be able to invoke this service by a procedure call such as ‘Exit {A"}’, where A" is the object to 
be edited. This procedure call is equivalent to the assertion ‘Edit(A,X)’, where A is a relation- 
surrogate for the agent performing the call. It can be seen that the call entails placing the tuple 
< A,X> in the Edit relation, which can be thought of as putting the message < A,X> in the Edit 
mailbox. 

Now, this usage pattern has several consequences. First, users of services must have insert rights to 
the relations used for requesting these services. Second, users of services should not have delete rights 
for these relations, since that would permit them to delete other users’ requests (postal patrons can’t 
take mail out of public mail-boxes). Further, users should not have read rights, since that would per- 
mit them to discover the requests made by other users. 

Thus it can be seen that the user of such a service-request relation should have insert^only rights to 
that relation. On the other hand, the implementor of the service must have full rights to the relation, 
otherwise it will be unable to read and delete the requests as they are serviced. 

Arrangements such as these are easily accomplished by means of the directory structure previously 
described. For example, suppose that we have two directories: ‘Public’ contains aJl the names gen- 

erally available to users, and ‘EditDir’ contains all of the (public and private) objects and relations 
needed to implement the editor. The private version of the request relation is created and named by: 

Define {EditDir, “Requests”, newrel{)} 

The system procedure ‘newrel’ creates a new relation and returns a capability for that relation that bears 
full rights. Within the implementor’s directory (EditDir) this capability will be known as ‘Requests’. 

To make the request relation available to potential users, we must give it a name in a publicly acces- 
sible directory. Since potential users should have insert-only rights to this relation the public name 
‘Edit’ is bound to an insert-only capability for Requests. This is accomplished by executing the follow- 
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ing call with EditDir as the current directory: 



Define {Public, ‘‘Edit’\ insertonly {Requests}} 

The system procedure ‘insertonly’ is used to produce the reduced-rights capability that is made publicly 
available. 

The basic approach illustrated above can be extended to more complicated directory structures and 
more complicated sharing and access policies. 

4.5 Hierarchical and Nonhierarchical Classification 

Classification and simulation go hand in hand. It is no coincidence that a class construct appeared in 
Simula 67, a simulation language, long before it appeared, or its value was recognized, in other 
languages. The reason is simple: in a simulation of any complexity it is infeasible to describe the 

behavior of every individual object. Rather, it is necessary to group objects into classes of similarly- 
behaving individuals, so that their common behavior can be described just once. At root this is the 
same reason we seek scientific laws. 

We have already shown how Q supports a simple (one level) classification system. A rule such as 

*Define (a, d, n, x), Directory (d) => Binds (d, n, z), a (x) 

is part of the description of the behavior of Directory objects. 

The integrity of Directories as abstract objects can be ensured by making the following rights pub- 
licly available: 

Define — insert^only 
Directory — read-only 
Binds — no rights 

‘Define’ has insert^only rights because it is used for requesting services; ‘Directory’ has read-only rights 
because it is used as the tag for Directory objects; and ‘Binds’ has no publicly accessible rights because 
it is part of the internal structure (implementation) of Directories. 

In more complex systems it is economical to factor common behavior out of several classes of 



objects; that is, to treat several classes as species under a common genus. To support this hierarchical 
classification Simula and Smalltalk permit classes to be subclasses of other classes. In the same result 
can be achieved by the Path structure previously described. In effect, directories correspond to the 
classes whose behavior they encapsulate. 

Other researchers have described the limitations of a purely hierarchical classification system jGold- 
stein80| . In these situations it is convenient for a class to be able to have more than one immediate 
superclass. Nonhierarchical classification can be handled in fl by arranging for the Path to thread in 
the desired order through the directories corresponding to the superclasses. 

It is our goal that the flexibility of Dyad’s naming and capability system will encourage experimenta- 
tion with nonhierarchical and other classification policies. 

5. Applications 

To add investigation and evaluation of this kind of object-oriented programming we have developed a 
prototype implementation of a programming environment for a simple applicative language. This 
implementation is described in detail in [ MacLennanSS] . The following table shows the number of 
rules required for programming several major components of the system: 



n Rules 


Component 


22 


Parallel Interpreter 


9 


Pretty Printer 


16 


Code Generator 


14 


Debugger 


24 


Language-Specific SDE 


37 


Universal SDE 


122 


TOTAL 



To convey some idea of the complexity of actual rules we show two rules from this programming 
environment. The first rule is from a parallel expression evaluator. In the pseudo-natural notation it 
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is: 

If a function is the meaning of the operator of an application, given value-1 is the value of the left 
argument of the application, and given value-2 is the value of the right argument of the application 

then the function of value-1 and value-2 is the value of the application. 

In the predicate notation it is: 

Appl(i:), Op(A^,jE:), Left(A,jE:), Right(r,jE:), Meaning(/’,7V), *Value( C/,X) , *Value( K, Y) 

Value (F[U,V], E), 

Appendix B includes the complete H definition of a combined parallel evaluator/un parser for an arith- 
metic expression language. These rules are in the dialect of accepted by the McArthur interpreter 
[ McArthur84] . 

A language-independent syntax-directed editor is used as another component of the example system. 
For example, the following rule moves the cursor to the leftmost daughter of the current node: 

*Command(in) , *Cursor( n, / ) , Subnode ( n ,/, m ) , Type(m,t), LeftField( t ) 

=> Cursor( m,g). 

The second example is a rule from a different universal (i.e., table driven) syntax-directed editor: 

*Command(in) , CurrentNode( , Type[V^E)j 
AssumedTemplate ( T, V), FirstSelector( , T), 

Component( ,£') 

SetCurrentNode( A) , Com m an d( display) . 

The syntax-directed editor is explained in detail in [ MacLennanSSj . This report also discusses the 
application of similar techniques to the interactive creation and modification of other data structures 
represented by relations. 

For another example we consider a simple version of Reed’s file system [Reed78j. The following 
rules allow a value to be read, effective at any time, and record the time of the latest read: 



Read(/4 , r), Value( r, r, j ) , LastRead( r,t ) , T^t => A{i). 



*Read(yl,r), Value( r, r,z ) , *La5LRead( r j) , T> i La5tRead( r , 7) , /I ( x ) . 

The following rules allow an update of a value effective at a given time, but only if that time is later 
than the time of the last read: 

*Update( r, 7, t/) . LastRead( r,i ) , T> t => Value ( r, 7, i/) . 

*Update( r, 7, y ) , LastRead( r,t) , t =^> AbortUpdate ( 7) . 

Since the users are considered objects in the system, they can interact with the system by performing 
searches, inserts and deletes on relations for which they have the appropriate capabilities Dennis66]. 

6. Implementation 

6.1 Declarations and Second Order Relationships 

We are investigating several techniques to keep the implementation of the Dyad system acceptably 
efficient. These involve both the more efficient representation of relations, and more efficient determi- 
nation of the rules eligible for application. 

Both goals are accomplished by giving users the ability to put declarative information about relation- 
ships into the object-relationship space. These second order relationships have a role similar to declara- 

tions in conventional languages, that is, they can be used for documentation, error checking and 
improved performance. Unlike declarations in most other languages, they are completely optional. The 
philosophy is that if programmers have information about the relationships that they think it would be 
useful to tell the system or other users, then they can do so. However, there is no obligation for them 
to provide this information or for the system or other users to make use of it. 

We give a few examples of these second order relationships. It is frequently useful to know the adi- 
city of a relationship and the types of values and objects it can relate. This information can be made 
available in the ‘Degree’ and ‘Domain’ relationships. For example, ‘ Degree ( R ,n ) ’ means that the 
degree of R is n, that is, all the tuples in R are n-tuples. Similarly, ‘ Domain( P, ^ ,/? ) ’ means that 
domain k (i.e., the k th. argument position) of relationship R is P, where P either is a type 
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membership predicate (Boolean valued total function) , or is degree 1 relationship (finite predicate). 

Another useful second order relationship is ‘Indexed’: ‘Indexed( i? ’ means that R is indexed on 
its k ih. argument, that is, the values of the ^ th argument must be unique. Knowing that a relationship 
is indexed permits the testing of the cause parts of rules to be done much more efficiently. To see an 
example of an indexed relationship, consider the following four assertions: 

Degree (Op, 2) 

Domain (string, 1, Op) 

Domain (Appl, 2, Op) 

Indexed (Op, 2) 

These tell us that relationship ‘Op’ has two columns, the first of which holds strings and the second of 
which holds members of the relationship called ‘Appl’. Furthermore, Op is indexed on its second 
column. Thus, if n is an object such that Appl(n) is true, then there is at most one string s such that 
Op(^ ,n). In effect Op is a finite partial function, or table, mapping Appl objects to strings. 

Relationships representing finite partial functions (tables) are so common that a special abbreviation 
is provided for them. The assertion ‘Function( f ,D,/2 ) ’ is equivalent to the four assertions 

Degree (F,2) 

Domain (/? , 1,F) 

Domain (D, 2,F) 

Indexed (F,2) 

Thus, the previous assertion about Op can be expressed ‘Function (Op, Appl, string)’, which means 
that Op is a (finite, alterable) function from Appl objects into strings. 

It is our intention to improve performance by allowing various representations for relationships 
(e.g., linked lists, hash tables, relational databases). Second order relationships allow the programmer 
to give the system suggestions about the representation to use. For example, ‘Repr (Op, hash)’ sug- 
gests that a hash table be used to represent Op. 
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6.2 Prototype Implementations 



Several prototype Implementations of Dyad have been completed The first prot,ot>'pe was implemented 
in LISP. This prototype supp>orted only one representation of relationships: lists of tuples. 

The second prototype was also implemented in LISP, but supports multiple representations of rela- 
tions to improve performance. This prototype interpreter accepts rules in a tree form that can be gen- 
erated either by a parser written in LISP, or by a syntax-directed editor. The table-driven syntax- 
directed editor in this case is especially interesting because it is written as Q rules operating on a trans- 
lation grammar expressed in the H object-relationship space. Thus we have successfully involuted the 
system, having H programs generate H programs. The table-driven syntax-directed editor is described 
in [MacLennan85] . 

The third prototype is intended for increased performance. The interpreter is coded in C and pro- 
vides access to the UNIX shell for various utility and convenience functions. An interpreter for the 
applicative language (A component) also has been completed. The third prototype, like the second, 
operates on rules in a tree form that can be generated either by a universal syntax- directed editor or by 
a conventional parser. In this case, however, the editor has been programmed in Pascal and the parser 
generated by YACC. A complete description of the third prototype can be found in [Me Arthur84] ; it is 
the system on which the example in Appendix B runs. 

6.5 Status 

The two languages (A and Q ) are stable, but subject to revision based on experience. The Dyad sys- 
tem is being evaluated by being used to describe and prototype a variety of applications. Several of 
these, including preliminary performance measurements, are described in [ McArthur84] . This 
approach is giving us experience in programming realistic problems. We are also experimenting with 
changes to Q to increase its knowledge representation capabilities. 

Alternate notations and visual representations for rules are being evaluated. For example, we are 
investigating a two-dimensional form based notation that allows transactions to be visualized as the 
arrival and distribution of forms. This might be useful in office automation applications. 
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APPENDIX A: SYNTAX OF n 



Session = statement — list . 
statement - list = statement ; • • 

( rule else statement 



statement = 



effect 



compound — rule = rule [ else statement 
rule = cause ==> effect 
cause = [if condition , * * • 



condition = 



inquiry 



inquiry = primary ( tupl — pattern 
pattern , ‘ ’ | 



tupl — pattern — 



pattern = 



pattern : pattern 
free- variable] 



expression 



} 



free- variable = i • l / i 
' \ variable] 

effect = [/ransaction , ■ • * 

/ \ 

assertion 

denial 
call 

seq — block 



transaction — 



\ 






assertion = predication 
denial = ^ predication 

predication — primary ( arguments ) 
call = primary { arguments } 
arguments = [ expression , ' ‘ ] 

seq — block = { statement — list } 

expression = [expression V) conjunction 
conjunction = [conjunction A] [H relation 



relation 



relator - 
simplex 
term = 

factor — 
primary 

primitive 



constant 



= [simplex relator] simplex 

- \ simplex term 

[term factor 

_ primary 

= primitive [: primary] 

( \ 

constant 

[@ ] variable 

primitive [ arguments ] 

— ( expression ) 

^ / 

J expression , • * * 

I 1 expression : expressio 

call 

rule — denotation 

V ; 

/ \ 

digit ^ 

chan 

.... ) 

nil 

V 





rule —denotation 



<< { compound — rule . } >> 



APPENDIX B; INTERPRETER. UNPARSER FOR SMALL LANGUAGE 



! Rules and associated definitions for a universal 
! interpreter/unparser for a small language of 
! arithmetic expressions. 

! Relations 

define {root, ’T)val”, newrelj}); 
define {root, 'Oheck", newrel{}}; 
define {root, 'Value”, newrel{}}; 

define {root, ”Appl”, newrel{}}; 
define {root, ”0p", newrel{}}; 
define {root, ’Teft”, newrel{}}; 
define {root, "Right”, newrel{}}; 
define {root, "Con”, newrel{}}; 
define {root, ”Litval”, newrel{}}; 

define {root, "Meaning”, newrel{}); 
define {root, ’Template”, newrel{}}; 
define {root, "Explanation”, newrel{}); 

define {root, ’CurrentNode”, newrel{}}; 

! Functions 

fn Id [ x] : x; 
fn Sum [x,y]: x -h y; 
fn Dif |x,y]: x - y; 
fn Product [x,y]: x * y; 



fn Quotient x,y]: 

if y = 0 -> i ’’error", 1 
else X / y; 

fn IsErrorcode [w]: 

if ^sListjw] ; w = Nil -> Nil 
else first[w] = "error"; 

fn upSum [x,yj: "(" -f x ^ " -h y + ") "; 
fn upDif [x,y]: "("-t- x- y+ 

fn upProd [x,y]: "( " ^ x ^ "x y ^ ") "; 
fn upQuot [x,y] : x + " / " -r y -h ")". 

! Built-in Tables 

Meaning (Sum, "-r "); 

Meaning (Dif, 

Meaning (Product, ’be"); 

Meaning (Quotient, "/"); 

Meaning (Id, "lit"); 

Template (upSum, ”-r ") ; 

Template (upDif, "-"); 

Template (upProd, ’be"); 

Template (upQuot, "/"); 

Template (int_str, "lit"); 

Explanation ("incomplete program", [’^rror", 0]); 
Explanation ("division by zero", ("error", l]); 
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the Rules 



define {root, ’'EvalUn parseRules”, < < 

! Constant node 

if *Eval (class, e), Con (e), Litval (v,e), class (f, ’'lit”) 
-> Value (class, f(v], e); 

! Application node: Analysis rule 

if ’^Eval (class, e), Appl (e), Left (x,e), Right (y,e) 

*> Eval (class, x) , Eval (class, y) ; 

! Application node: Synthesis rules 

if *Value (class, u,x), *Value (class, v,y), 

Appl (e). Op (n,e), Left (x,e). Right (y,e), class (f, n) 
-> Check (class, f[u,v], e); 

if *Check (class, w, e), ^sE^ro^code [w] 

-> Value (class, w, e); 

if *Check (class, w, e), IsErrorcode [w]. 

Explanation (s, w), *CurrentNode (q) 

-> displayn {s}, CurrentNode (e) 

>> }• 

! activate the rules 

act {EvalUnparseRules}. 

CurrentNode (Nil). 

displayn (”Evaluator/Un parser loaded"}. 



- 27 - 



INITIAL DISTRIBUTION LIST 



Defense Technical Information Center 
Cameron Station 
Alexandria, VA 22314 

Dudley Knox Library 
Code 0142 

Naval Postgraduate School 
Monterey, CA 9394 3 

Office of Research Administration 
Code 01 2A 

Naval Postgraduate School 
Monterey, CA 9394 3 

Chairman, Code 52 
Department of Computer Science 
Naval Postgraduate School 
Monterey, CA 93943 

Associate Professor Bruce J. MacLennan 
Code 52ML 

Department of Computer Science 
Naval Postgraduate School 
Monterey, CA 93943 

Dr. Robert Grafton 
Code 433 

Office of Naval Research 
800 N. Quincy 
Arlington, VA 22217-5000 

Dr. David Mizell 
Office of Naval Research 
1030 East Green Street 
Pasadena, CA 91106 

Professor Jack M. Wozencraft, 62Wz 
Department of Electrical and Comp. Engr. 
Naval Postgraduate School 
Monterey, CA 93943 

Professor Rudolf Bayer 
Institiit fur Informatik 
Technische Universitat 
Postfach 2024 20 
D-8000 Munchen 2 
West Germany 

Dr. Robert M. Balzer 

use Information Sciences Inst. 

4676 Admiralty Way 
Suite 10001 

Marina del Rey, CA 90291 



2 

2 

1 

40 

12 

1 

1 

1 

1 

1 



- 28 - 



Mr. Ronald E. Joy 
Honey^vell. Inc. 

Computer Sciences Center 
10701 LyndaJe Avenue South 
Bloomington, Ml 55402 



Mr. Ron Laborde 
INMOS 
White friars 
Lewins Mead 
Bristol 

Great Britain 1 

Mr. Lynwood Sutton 
Code 424, Building 600 
Naval Ocean Systems Center 

San Diego, CA 92152 1 

Mr. Jeffrey Dean 

Advanced Information and Decision Systems 
201 San Antonio Circle, Suite 286 

Mountain View, CA 94040 1 

Mr. Jack Fried 

Mail Station D01/31T 

Grumman Aerospace Corporation 



FVofessor S. Ceri 
Laboratorio di CaJcolatori 
Departimento di Elettronica 
Politecnico di Milano 
20133 - Milano 



Beth page, NY 11714 



1 



Mr. Dennis Hall 

New York Video text 

104 Fifth Avenue, Second Floor 

New York, NY 10011 



1 



Italy 



1 



Mr. A. Dain Samples 
Computer Science Division - EECS 
University of California at Berkeley 
Berkeley, CA 94720 



1 



- 29 - 



DUDLEY KNOX LIBRARY 




3 2768 00340222 3 



